Zum Hauptinhalt springen

Chapter 20

The Data Manager

"Within the Cube Framework, runtime systems never search for authored content. They request it."

Why This Chapter Exists​

The previous chapters introduced the Runtime Host and the Runtime Assembly process.

Neither of these systems knows where authored assets originate.

This separation is intentional.

Within the Cube Framework, locating authored content is the responsibility of the Data Manager.

The Data Manager forms the architectural bridge between authored knowledge and runtime construction.

Separating Knowledge from Access​

Authoring data exists independently of runtime.

Weapons are stored in databases.

Weapon Parts are stored in databases.

Stat Modifiers are stored in databases.

Side Effects are stored in databases.

Runtime systems should never know where this information resides.

Instead, they communicate exclusively with the Data Manager.

The Data Manager owns knowledge retrieval.

Runtime systems own runtime construction.

A Single Point of Access​

One of the primary goals of the Data Manager is consistency.

Every runtime system retrieves authored content through the same architectural entry point.

Whether requesting:

  • Weapon Definitions,
  • Weapon Parts,
  • Stat Modifiers,
  • or future asset types,

the request always follows the same architectural path.

This predictable access model simplifies both Runtime Assembly and future framework extensions.

Managing Databases​

The Cube Framework organizes authored content into dedicated databases.

Each database owns a specific category of information.

Rather than exposing these databases directly, the Data Manager builds internal lookup tables during initialization.

Runtime systems therefore never search databases manually.

They simply request the information they require.

The implementation remains centralized while authored content remains distributed.

Asynchronous by Design​

Authoring assets are loaded asynchronously whenever possible.

This allows runtime construction to continue without blocking the game thread unnecessarily.

The Data Manager coordinates these loading operations.

Once every required asset becomes available, the Runtime Assembly process continues automatically.

Runtime systems remain focused on construction rather than resource management.

Caching Runtime Requests​

Loading the same authored asset repeatedly would introduce unnecessary overhead.

The Data Manager therefore maintains runtime caches for previously loaded assets.

Future requests can often be satisfied immediately without additional loading.

Caching remains entirely transparent to the requesting system.

The Runtime Builder simply asks for authored content.

The Data Manager decides how that content is obtained.

Supporting Runtime Assembly​

Runtime Builder
    │
    ▼
Data Manager
    │
    ▼
Database Lookup
    │
    ▼
Asset Resolution
    │
    ▼
Loaded Assets
    │
    ▼
Runtime Builder

The Runtime Builder depends upon authored assets.

The Data Manager guarantees that these assets become available.

Neither subsystem performs the other's responsibility.

The Runtime Builder never searches databases.

The Data Manager never assembles runtime objects.

Together they form a clean architectural boundary between authored content and runtime construction.

A Foundation for Every Cube Module​

Although the current implementation serves the Weapon Framework, the architectural concept extends naturally across the Cube ecosystem.

Future Vehicle modules.

Equipment modules.

Character modules.

Each can introduce its own authored databases while preserving the same architectural relationship.

Runtime systems request authored content.

Data Managers provide it.

The responsibility remains unchanged.

Design Note​

Whenever a runtime subsystem requires authored content, avoid loading assets directly.

Instead ask:

"Should this request pass through the Data Manager?"

Centralized data access keeps runtime systems independent from asset organization.

Framework Law XX​

Within the Cube Framework, runtime systems request knowledge. Data Managers provide it.

Knowledge retrieval and runtime construction remain separate architectural responsibilities.

Looking Ahead​

Runtime objects can now access the authored information required for construction.

The next chapter explores how these assembled runtime objects become synchronized across the network while preserving the architectural separation established throughout the Cube Framework.

Revision History​

Version 1.0​

Initial publication.